home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Amiga Tools 5
/
Amiga Tools 5.iso
/
grafik
/
viewer
/
superviewel
/
superviewlibrary
/
docs
/
svsupport-docs
/
cpinfoformat.doc
< prev
next >
Wrap
Text File
|
1996-07-16
|
9KB
|
231 lines
The ControlPadInfo-FileFormat V12.5 (2.12.95)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Some applications might wish to enable the user to interactively
specify controlpad settings just when reading, writing or
processing an image and not before or after by setting preferences.
Until this will be managed by superview.library, superviewsupport.library
or the single modules by introducing new functions for handling this,
applications may take this information from ".cpinfo" files, where
the specific ControlPad entries are dynamically described.
Content
=======
- Structure in general
- Structure in detail
- Structure Entry Description in detail
- Examples
- Last Words and Exceptions
- Future
- Special configuration Standards
Structure in general
--------------------
Every CPInfo-File is constructed like an usual ControlPad file,
but in this case, the _order_ of the entries becomes meaningful.
These files are separated into SECTIONs, where any necessary
information about specific ControlPad entries are stored.
To allow easy enhancements and improvements on this format, there's
an important note:
- the number of sections is not limited
- each SECTION _must_ contain at least the entries described below
- each SECTION _may_ contain more entries, so that it might be
necessary to skip all the following entries until another "SECTION"
entry will be reached
- the order of the entries is _fixed_
- if any of the following _needed_ entries makes no sense,
it will still be present as a "dummy", thus just a Keyword
is placed there and no value is given via "="
- any single line should not exceed 255 characters
- as with usual ControlPad files, comments and blank lines are allowed
Structure in detail
-------------------
CPINFO ; identification
SECTION=<Name of ControlPad entry> ; the name of the entry
TYPE=<INTEGER|FLOAT|ASCII|NONE> ; type of data
; (signed or unsigned for
; INTEGER or FLOAT may
; be detected via MIN and MAX).
; NONE is used for KeyWords.
MIN=<Value> ; - minimum value for numbers
; - minimum length for strings
; - or empty ("MIN")
; Empty with KeyWords.
MAX=<Value> ; - maximum value for numbers
; - maximum length for strings
; - or empty ("MAX")
; Empty with KeyWords.
DEFAULT=<Default value for entry> ; what will be used if nothing
; is specified ?!
; Empty e.g. with KeyWords.
DESCRIPTION=<descriptive text> ; what does it do ?
MASK=<input mask> ; this one allows to separate
; choices and "free" enterings
; Empty with KeyWords.
WHEN=<READ|WRITE|ALWAYS|PREFS|NEVER> ; ask for it, when the user
; does reading or writing
; (SVObjects) ? Or always
; (SVDrivers/SVOperators) ?
; Or never ? (Undocumented)
; Or Just handle it as a real
; preferences thing ?
Structure Entry Description in detail
-------------------------------------
o A few words to the MASK entry:
Any entries which don't have a specific meaning (just comments)
or mutual exclude entries do have to begin with "<" and end with
">". Anything else are control sequences, qhich either are
to be supported or have to be ignored.
a) "<...>" or "<...|...|...>"
Usually you should print out this text as a little help for
the user, how to enter the data, e.g. into a string/integer gadget.
But if the string included by "<" and ">" does contain one or
more "|" these are meant as exclusice choices, which e.g.
might be represented as mx-, cycle- or listview-gadgets.
So you may a) present this mask to the user while editing a
string/integer gadget or b) parse it and just "filter" the input
via supplying appropriate input gadgets.
Please note, that the "MIN" and "MAX" values (if specified)
still have to be valid for this input (if the file definition
has been done correctly ;-)
So for a "MASK=<8|24>" these would equal "MIN=8" and "MAX=24".
But note, that this "mask" is not really meant to define ranges
with gaps, like "anything between 5 and 37, but except the numbers
between 33.3 und 36.5" 8-)
b) Control Sequences
MASK=_SVOBJECT means, that a file from "LIBS:svobjects"
has to be requested, which matches
"#?.svobject".
MASK=_SVDRIVER means, that a file from "LIBS:svdrivers"
has to be requested, which matches
"#?.svdriver".
MASK=_SVOPERATOR means, that a file from "LIBS:svoperators"
has to be requested, which matches
"#?.svoperator".
MASK=_FILE a file to be selected e.g. fromout a
requester (it is supposed, that the user
does the right choice).
Examples
--------
Anentry for a KeyWord might look like this:
SECTION=ANYDATATYPES
TYPE=NONE
MIN
MAX
DEFAULT
DESCRIPTION=Switches Datatypes support to ANY
MASK
WHEN=PREFS
An entry for a float value:
SECTION=SCALE_FACTOR
TYPE=FLOAT
MIN=0.1
MAX=2.0
DEFAULT=1.0
DESCRIPTION=Factor for scaling graphics
MASK=<Value>
WHEN=ALWAYS
An entry for an ASCII text:
SECTION=PACKMETHOD
TYPE=ASCII
MIN=4
MAX=4
DEFAULT=NUKE
DESCRIPTION=How to pack the written data
MASK=<XPK-Packer>
WHEN=WRITE
An example for an ignoreable Keyword:
SECTION=DEBUGMODE
TYPE=NONE
MIN
MAX
DEFAULT
DESCRIPTION=Enables debugging mode with Confirm-Requesters
MASK
WHEN=NEVER
Last Words and Exceptions
-------------------------
So you see, that it's easy to describe any of the existing ControlPad
variations this way.
The "WHEN" statement is a help for applications to decide, whether
and when to allow changing of specific ControlPad entries.
Applications should either ignore entries of type "WHEN=NEVER"
or prepared to handle slightly differing entries, like
e.g. TYPE=INTEGER entries with a non-set default value.
(An example had been the "AVAILMEM" switch of interim versions
of JPEG.svobject - which was both: a keyword and a common setting,
but should never be changed during runtime.)
"WHEN=NEVER" is just for options with experimental state or
debugging purposes.
Future
------
In the future, there may be a function in superview.library, which
allows passing a controlpad list to it, which then may be passed
to the attached SVObject/SVDriver/SVOperator as a "local" setting,
which will override the "global" ControlPad files.
So the CPInfo Files will be helpful for applications on how
to find out, which ControlPads might be possibly set.
Special configuration Standards
-------------------------------
For special cases it seems to be suitable to define a common
behavior, so that GUI-based and interactive selections for
those special cases may become independent from specific modules.
Applying operations to parts of images only (crop standard)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Suggested by Steve Quartly in 11/95
Operators and other modules, which allow to apply their specific
operations to either the whole given image or only a defined
part of it, should use the following controlpads as a standard
for allowing the application to better visualize the process
of selecting the concerned parts of the graphics.
REGION=<ENTIREIMAGE|RECTANGULAR>
; if this one exists, you have the choice.
; Then, if REGION=ENTIREIMAGE, the following are supposed to be
; 0, 0, width, height, otherwise they have to be specified.
LEFTEDGE=<Value smaller or equal width>
TOPEDGE=<Value smaller or equal height>
WIDTH=<width of shape>
HEIGHT=<height of shape>
; just like opening a window
--
Andy, 2.12.95